Continuous replication for session initiation protocol based communication systems

ABSTRACT

User defined routing rules are managed within a primary/backup architecture through continuous replication between home servers and their corresponding presence servers in an automatic manner. User set-up rules are stored and published by a designated presence server to home servers on which the user can register including the user&#39;s home registrar and any backup registrars. Changes to the rules may be disseminated and synchronized through comparison of versions and exchange of batches between the presence server and registrars.

BACKGROUND

Primary/backup failover/failback models are used by conventional serverbased systems to assign resources to clusters, where typically a standbybackup cluster takes over from the primary cluster if the primarycluster becomes unavailable. While reliability is a key requirement forany server based system, minimizing degradation of user experience inthe event of a failure means tightly controlled downtime in SessionInitiation Protocol (SIP) based communication systems that facilitatereal time communications such as audio or video communications.

In creating primary/backup relationships for assigning users toclusters, some of the questions that need to be answered include whetherthe user will be connected to the primary or backup cluster, a locationfor storing routing rules for the user, and how changes to the routingrules are to be disseminated to the primary and backup clusters. Thechallenges with such infrastructures include how to process calls to theuser if the primary and/or backup clusters are down, how to processcalls to the user when there is network portioning, and how toaccomplish these processing tasks without manual intervention.

SUMMARY

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This summary is not intended to exclusively identify keyfeatures or essential features of the claimed subject matter, nor is itintended as an aid in determining the scope of the claimed subjectmatter.

Embodiments are directed to managing user defined routing rules within aprimary/backup architecture in an automatic manner without degradinguser experience. According to some embodiments, user set-up rules may bestored and published by a designated server to servers on which the usercan register including the user's home registrar and any backupregistrars. Changes to the rules may be disseminated and synchronizedthrough comparison of versions and exchange of batches between thestoring server and registrars.

These and other features and advantages will be apparent from a readingof the following detailed description and a review of the associateddrawings. It is to be understood that both the foregoing generaldescription and the following detailed description are explanatory anddo not restrict aspects as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram illustrating an example unified communicationssystem, where embodiments may be implemented for managing routing rulesdefined by a user within a primary/backup cluster architecture;

FIG. 2 is a conceptual diagram illustrating example primary and backupserver clusters that may manage routing rules for user in anarchitecture according to embodiments;

FIG. 3 illustrates example exchanges between a user, his/her registrar,and presence server in a scenario of the user changing published rulesafter registration;

FIG. 4 illustrates example exchanges between a branch office registrarand presence server for updating replication information;

FIG. 5 illustrates example data models in updating changes to userrouting rules;

FIG. 6 is a networked environment, where a system according toembodiments may be implemented;

FIG. 7 is a block diagram of an example computing operating environment,where embodiments may be implemented; and

FIG. 8 illustrates a logic flow diagram for a process of updating anddisseminating user routing rules in primary/backup cluster architectureaccording to embodiments.

DETAILED DESCRIPTION

As briefly described above, routing rules for calls associated with auser may be managed in a primary/backup communication networkarchitecture by having registrars associated with the user submit theirreplica versions to a presence server storing the routing rules. Anexchange of batch versions may follow along with a comparison of theversions at the registrars such that each registrar can determine whichbatches it needs to be synchronized with the presence server. In thefollowing detailed description, references are made to the accompanyingdrawings that form a part hereof, and in which are shown by way ofillustrations specific embodiments or examples. These aspects may becombined, other aspects may be utilized, and structural changes may bemade without departing from the spirit or scope of the presentdisclosure. The following detailed description is therefore not to betaken in a limiting sense, and the scope of the present invention isdefined by the appended claims and their equivalents.

While the embodiments will be described in the general context ofprogram modules that execute in conjunction with an application programthat runs on an operating system on a personal computer, those skilledin the art will recognize that aspects may also be implemented incombination with other program modules.

Generally, program modules include routines, programs, components, datastructures, and other types of structures that perform particular tasksor implement particular abstract data types. Moreover, those skilled inthe art will appreciate that embodiments may be practiced with othercomputer system configurations, including hand-held devices,multiprocessor systems, microprocessor-based or programmable consumerelectronics, minicomputers, mainframe computers, and comparablecomputing devices. Embodiments may also be practiced in distributedcomputing environments where tasks are performed by remote processingdevices that are linked through a communications network. In adistributed computing environment, program modules may be located inboth local and remote memory storage devices.

Embodiments may be implemented as a computer-implemented process(method), a computing system, or as an article of manufacture, such as acomputer program product or computer readable media. The computerprogram product may be a computer storage medium readable by a computersystem and encoding a computer program that comprises instructions forcausing a computer or computing system to perform example process(es).The computer-readable storage medium can for example be implemented viaone or more of a volatile computer memory, a non-volatile memory, a harddrive, a flash drive, a floppy disk, or a compact disk, and comparablemedia.

Throughout this specification, the term “platform” may be a combinationof software and hardware components for managing multimodalcommunication systems or redundancy systems. Examples of platformsinclude, but are not limited to, a hosted service executed over aplurality of servers, an application executed on a single server, andcomparable systems. The term “server” generally refers to a computingdevice executing one or more software programs typically in a networkedenvironment. However, a server may also be implemented as a virtualserver (software programs) executed on one or more computing devicesviewed as a server on the network. More detail on these technologies andexample operations is provided below.

FIG. 1 includes diagram 100 illustrating an example unifiedcommunications system, where embodiments may be implemented for managingrouting rules defined by a user within a primary/backup clusterarchitecture. A unified communication system is an example of moderncommunication systems with a wide range of capabilities and servicesthat can be provided to subscribers. A unified communication system is areal-time communications system facilitating instant messaging,presence, audio-video conferencing, web conferencing, and similarfunctionalities.

In a unified communication (“UC”) system such as the one shown indiagram 100, users may communicate via a variety of end devices (102,104), which are client devices of the UC system. Each client device maybe capable of executing one or more communication applications for voicecommunication, video communication, instant messaging, applicationsharing, data sharing, and the like. In addition to their advancedfunctionality, the end devices may also facilitate traditional phonecalls through an external connection such as through PBX 124 to a PublicSwitched Telephone Network (“PSTN”). End devices may include any type ofsmart phone, cellular phone, any computing device executing acommunication application, a smart automobile console, and advancedphone devices with additional functionality.

UC Network(s) 110 includes a number of servers performing differenttasks. For example, UC servers 114 provide registration, presence, androuting functionalities. Routing functionality enables the system toroute calls to a user to anyone of the client devices assigned to theuser based on default and/or user set policies. For example, if the useris not available through a regular phone, the call may be forwarded tothe user's cellular phone, and if that is not answering a number ofvoicemail options may be utilized. Since the end devices can handleadditional communication modes, UC servers 114 may provide access tothese additional communication modes (e.g. instant messaging, videocommunication, etc.) through access server 112. Access server 112resides in a perimeter network and enables connectivity through UCnetwork(s) 110 with other users in one of the additional communicationmodes. UC servers 114 may include servers that perform combinations ofthe above described functionalities or specialized servers that onlyprovide a particular functionality. For example, home servers providingpresence functionality, routing servers providing routing functionality,and so on. Similarly, access server 112 may provide multiplefunctionalities such as firewall protection and connectivity, or onlyspecific functionalities.

Audio/Video (A/V) conferencing server 118 provides audio and/or videoconferencing capabilities by facilitating those over an internal orexternal network. Mediation server 116 mediates signaling and media toand from other types of networks such as a PSTN or a cellular network(e.g. calls through PBX 124 or from cellular phone 122). Mediationserver 116 may also act as a Session Initiation Protocol (SIP) useragent.

In a UC system, users may have one or more identities, which is notnecessarily limited to a phone number. The identity may take any formdepending on the integrated networks, such as a telephone number, aSession Initiation Protocol (SIP) Uniform Resource Identifier (URI), orany other identifier. While any protocol may be used in a UC system, SIPis a commonly used method.

SIP is an application-layer control (signaling) protocol for creating,modifying, and terminating sessions with one or more participants. Itcan be used to create two-party, multiparty, or multicast sessions thatinclude Internet telephone calls, multimedia distribution, andmultimedia conferences. SIP is designed to be independent of theunderlying transport layer.

SIP clients may use Transport Control Protocol (“TCP”) to connect to SIPservers and other SIP endpoints. SIP is primarily used in setting up andtearing down voice or video calls. However, it can be used in anyapplication where session initiation is a requirement. These includeevent subscription and notification, terminal mobility, and so on. Voiceand/or video communications are typically done over separate sessionprotocols, typically Real Time Protocol (“RTP”).

A UC system may provide a platform for multimodal communications.Clients in such a system may be assigned home servers (or registrars)servicing communication requests from users. The home servers may beestablished as part of primary clusters. A cluster is a group ofhomogenous servers fronted by a load balancer and visible to the clientas a single entity. Each cluster may have one or more backup clusters,each cluster having one or more physical/logic servers. When acommunication request is received for a user at any server of the UCsystem, it may be directed to the primary home server cluster initially.If that cluster is down, a designated backup cluster may be tried next.If the primary and the backup clusters are not available, alternativemethods such as routing the request to PSTN may be attempted. Each usermay also be assigned to a presence cluster, which stores routing rulesset up by the user and publishes the information to registrars that maybe used by the user.

While the example system in FIG. 1 has been described with specificcomponents such as mediation server, A/V server, home server, presenceserver, and similar devices, embodiments are not limited to thesecomponents or system configurations and can be implemented with othersystem configuration employing fewer or additional components.Functionality of systems managing continuous replication in aprimary/backup architecture may also be distributed among the componentsof the systems differently depending on component capabilities andsystem configurations. Furthermore, embodiments are not limited tounified communication systems. The approaches discussed here may beapplied to any data exchange in a networked communication environmentusing the principles described herein.

FIG. 2 is a conceptual diagram illustrating example primary and backupserver clusters that may manage routing rules for user in anarchitecture according to embodiments. Network 210 in diagram 200 may bea UCN as discussed above. Network 210 may include a number of serversdiscussed above and facilitate communications for clients 202. Clients202 represent end point devices (or applications) for users. A user maybe associated with more than one end point, zero or more of which may beactive at any given time.

Edge server 228 and firewall 226 are an example of a split access serverfunctionality. Firewall 226 provides protection for connections withother networks such as Internet 220, while edge server 228 providesconnectivity through the perimeter network. According to someembodiments, one or more edge servers may provide connectivity toclients connected to network 210 with clients through other networks.

As mentioned above, clients 202 may be assigned home server/clusterssuch as clusters 236 and 230. In a system according to embodiments, aclient may connect to the network through their home registrar, but alsothrough other registrars (e.g. if the user moves physically to adifferent location with their end point and connects to the network).Home clusters may be set up as each other's backups or other servers(e.g. 238) within the network may be configured as backup clusters forone or more home clusters. Furthermore, each home cluster may beassociated with a presence server or presence cluster 234. Presenceservers may also have backup clusters associated with them.

A request for communication with a particular user may be routed by anyserver that receives the request to the home server (registrar) of thatparticular user, which may implement the rules set up by the user in anautomatic manner. Thus, a resource can be contacted reliably in acomplex system comprising clusters that have backups and that have othernon-networking mechanisms configured for contacting a user.

The information of <Home Registrar cluster, Presence Cluster>combination assigned to a user may be made globally available to allclusters in the deployment. The backup configuration information for thehome registrar and presence clusters may also be available globally. Therouting rules stored in the presence cluster may be made available toany servers with which the user may register. This includes the serversin a particular home registrar cluster of the user and servers in thebackup registrar cluster for the user.

Routing rules may include instructions for forwarding calls intended forthe user to other recipients when the user is unavailable or does notwish to take calls. The rules may further include time and/orrelationship based routing of calls based on a caller type or identity,end point selection (e.g. if the user is on the move, calls may bedirected at the user's mobile device instead of their desktop device),and comparable ones. An example of a rule set up by the user is the timelimit to ring the user's phone before sending the call to voice mail.For example, if the user sets the timeout to be 20 seconds, then theserver waits for 20 seconds for the user to answer the call and thenre-directs the call to voicemail. An example of a more complicated rulemay involve setting up a supervisor-assistant relationship andprocessing a call in this context.

The data that is required to route a call to a user following therouting rules set up by the user may be referred to as routing payload.Routing payload may include, but is not limited to, call forwardingrules, privacy relationship settings, hierarchical relationship (e.g.supervisor-assistant) settings, and comparable ones. In a systemaccording to embodiments, the presence cluster may be the master for therouting payload of a user. A user may be allowed to change the routingpayload when the presence cluster is available. While scenarios relatedto changing routing payload when the presence cluster is unavailable maybe addressed using the principles described herein, such scenariosinvolve multi-master distributed systems, which are inherently complex.

In order to process a call for a user, the routing payload for the userneeds to be available on the server that is processing the call. Alogical approach may be obtaining the routing payload for the user fromthe presence cluster and employing to process the call. However,challenges for this approach include what the processing server (i.e.home server) is supposed to do if the presence cluster is down at thetime of the call; if the server processing the call cannot contact thepresence cluster for the user due to network partitioning; and if thepresence server was up when the user registered but then went downbefore the call was processed.

Alternatively, the home server may contact the presence serverperiodically to get the routing payload for a user and cache it locally.When a call for the user needs to be processed, the home server may usethe cached data to complete the call. This alternative approachencounters a roadblock when the user changes the routing payload betweenperiodic queries of the presence server. Any calls received in thatperiod are processed according to older and no longer valid rules.

While the replication processes and systems are described in conjunctionwith routing rules herein, embodiments are not limited to routing rules.Any user information that is required to handle calls (in any modalityincluding, but not limited to, audio) may be replicated based on theuser's preference implementing the principles described here.Furthermore, system structures for implementing embodiments are notlimited to single primary-backup architectures. For example, nestedbackup structures may also be used for synchronizing the backup systemsthrough a single master by continuous replication.

A system according to embodiments enables the routing rules for the userto be in effect immediately after they have been set and to be honoredwhen the health state of servers change. Thus, there are two mainphases: connected server replication and offline replication.

FIG. 3 illustrates example exchanges between a user, his/her registrar,and presence server in a scenario of the user changing published rulesafter registration. When a user (e.g. user 342 of diagram 300) registerson a home server (registrar 344), the home server may notify thepresence server (346) of the event. This enables the presence server toshow the updated presence state for the user (e.g. online, offline,etc). In a system according to embodiments, the notification may also beused to obtain the current routing payload for the user at the time ofregistration. Use of the registration notification for update ensuresthe availability of the latest routing payload on the home server withwhich the user registers if the presence server is up at the time ofregistration and goes down subsequently.

Similarly, when a user changes their routing payload, the presenceserver may send a message to the registrar via which the user isconnected. In response to this message, the registrar may cache the newpayload ensuring that the registrar has the latest information.

Following diagram 300, user 342 registers with connected registrar 344at exchange 351 followed by the connected registrar 344 notifyingpresence server 346 of the user at exchange 352. The notificationmessage may include versions of the routing rules at the registrar 344.In response, presence server 346 may compare the received versions tothe current ones stored by the presence server and send back currentpublications (routing rules) of the user at exchange 353 if there is adifference between the versions.

At a later time, user 342 may decide to change one or more of theirrouting rules and submit the changes to the registrar 344 at exchange354. Registrar 344 may route the request to change the publications topresence server 346 at exchange 355, which may process/store the changesand send back the current publications (routing rules) of the user withthe new versions to registrar 344 at exchange 356.

FIG. 4 illustrates example exchanges between a branch office registrarand presence server for updating replication information. As discussedearlier, a user is assigned to a <Registrar Cluster, Presence Cluster>.A registrar cluster is associated with presence server. The registrarcluster may periodically query the presence cluster for changes to therouting payload of users who may potentially connect to it.

For example, if registrar cluster C1 is the backup cluster for registrarcluster C2, then C1 may query its presence server for the routingpayload of users who are: (1) assigned to C1 since these users canregister with C1 when the presence server is down and their payloads aretherefore needed; and (2) assigned to C2 since users on C2 can registeron C1 if C2 is down and the presence server can be down at the same timetoo (thus, their payloads are needed as well). If C1 is not the backupfor C2, however, only users who can register on C1 are the users homedon C1. By limiting periodically downloaded routing payload to usershomed on a particular registrar, system resources are preserved.Moreover, low end servers provisioned for a few users may not be able tosupport the routing payload of all the users in the deployment.

According to some embodiments, the presence cluster and the registrarcluster may agree on a common protocol that is designed to minimize thedata that is transferred. For example, if the presence server sends backthe data about all the applicable users every time, then the data beingsent across may remain the same even if no user has changed his routingpayload. The protocol may be designed in such a way that the data beingtransferred is reduced after the initial synchronization between theregistrar cluster and the presence cluster. Subsequent synchronizationswith the presence cluster may include the changes to user routingpayload.

Before addressing the call flow in diagram 400, enhanced communicationnetworks facilitating multi-modal communications (including dataexchange) may comprise a number of networks. Some of the services andmanagement processes may be performed centrally (e.g. at informationtechnology headquarters of an enterprise), while other services may beprovided in a distributed manner through branch offices. Thus, registrarservers may be classified as branch office (BO) servers or data center(DC) servers. DC servers may communicate directly with each other, whileBO servers may employ a standard protocol such as Hypertext TransferProtocol (HTTP).

Diagram 400 shows an example call flow between a BO registrar 462 and apresence server 464 following a data reducing protocol. Use of batchesand versions is an example implementation of maintaining the state onthe presence server in order to determine the changes to the data sincethe last synchronization. Any versioning scheme that accomplishes serverstate maintenance while reducing exchanged data may be employed usingthe principles described herein.

Upon registering a user, BO registrar 462 submits its clusteridentification (e.g. cluster fully qualified domain name “CFQDN”) and aversion of its currently stored replica routing payload in anotification message to presence server 464 at exchange 471. Theexchange may occur through HTTP since the registrar is BO. In responsepresence server 464 sends back the replica version of the routing rulesstored at the presence server and a list of batches along with theirversions at exchange 472. Next, BO registrar 462 may compute anymodified batches by comparing the list received from presence server 464to its versions and begin a process of requesting changed batches one ata time (473). The request exchange(s) 474 may include the clusteridentification and a batch identifier along with its version. Presenceserver 464 responds to the requests by sending batch deltas (475) asdescribed below.

According to some embodiments a major/minor versioning approach may beused. Presence server 464 may compute the items to be sent back usingthe following scheme. If the major version for a batch matches thatreceived from the replica, presence server may find the modifiedresources in each batch and consider items that have minor versiongreater than the minor version of the batch received from registrar ashaving been modified. If the major version for a batch is greater thanthat received from the replica, presence server may obtain a list of allusers in the batch. Then, presence server may send back the informationfor each user in the list created through the above steps if a user ishomed on the cluster that made the request or the cluster making therequest is the backup of the user's primary cluster. Presence server 464also sends back the major and minor versions.

After receiving each batch delta, BO registrar 462 may update batchversions at the registrar (476) and updating the replica version afterall batches are processed (476). This way, the entire routing rule datadoes not have to be transmitted back and forth between the registrarsand their corresponding presence servers. Thus, exchanged data isminimized while keeping the states of the presence servers and theirassigned registrars (home servers) synchronized in a reliable manner.

Some of the scenarios, where registrar—presence server synchronizationaccording to embodiments (continuous replication) may be implemented mayinclude: a user logging in and a call for the user arriving on theserver on which the user is registered; a user logging in and thepresence server going down, where the rule set by the user is stillhonored; a user logging in to a server which subsequently goes down, andthe user logging in to another server in the same cluster; and a user'sprimary cluster going down and the user registering on the backupcluster when the presence server is down. According to another examplescenario, a user may set their call forwarding rules and then go onvacation. At that time, the user not registered on any server in thesystem, but a call for the user is processed correctly. For example, theuser might set a rule indicating that all calls are to be forwarded tohis/her cell phone. This rule is honored even when the user's primarycluster is down and the calls are processed by his backup cluster, sincethe replica at the backup cluster is synchronized with the user'spresence server. Further examples of routing rule usage may include theuser requesting simultaneous alerts to different end points (e.g.desktop phone, mobile phone, etc.)

FIG. 5 illustrates example data models in updating changes to userrouting rules. As mentioned previously, a dual versioning systememploying major and minor versions may be used to keep track of changesto routing rules.

Diagram 500 illustrates example data models in such an architecture. Thedata models may include a major version and a minor version for eachbatch 584 identified by a batch identifier. Items 586 may be identifiedby a resource identifier of the user and include the associated batchidentifier and item minor version to indicate a status of each item(relative to the changes made by the user). Replicas 582 may beidentified by a replica identifier and include a replica clusteridentifier (identifying the cluster to which the replica belongs) and areplica version. A primary key may be used to uniquely identify each rowin the data table as shown in diagram 500.

The example systems in FIGS. 3, 4, and 5 have been described withspecific components such as presence servers, registrar servers, andsimilar ones, and particular exchange mechanisms. Embodiments are notlimited to communication systems according to these exampleconfigurations. An enhanced communication system employing continuousreplication according to embodiments may be implemented inconfigurations employing fewer or additional components and performingother tasks.

Furthermore, embodiments are not limited to enhanced communicationsystems. Continuous replication through batch versioning may beimplemented in other types of networks, where users and/or resources aremanaged by servers and server groups using the principles describedherein.

FIG. 6 is an example networked environment, where embodiments may beimplemented. A primary/backup cluster architecture employing continuousreplication as described previously may be implemented in a distributedmanner over a number of physical and virtual clients and servers. Such asystem may typically involve one or more networks such as PSTN 620,cellular network 630, and UCN 610. At least one of the systems may beimplemented in un-clustered systems or clustered systems employing anumber of nodes communicating over one or more networks.

A system according to embodiments may comprise any topology of servers,clients, Internet service providers, and communication media. Also, thesystem may have a static or dynamic topology. The term “client” mayrefer to a client application or a client device. A system according toembodiments may involve many more components, typical and relevant onesare discussed in conjunction with this figure.

Mediation server(s) 612 may provide signaling and media exchange betweenthe different systems. A PBX 622 and an RF modem 632 may be used forconnection between the PSTN and the cellular networks, respectively, andthe mediation server(s) 612. Client devices 601, 602, 603 communicatewith each other and with devices on other networks through UCN 610. TheUC system may include a one or more specialized or combination serversfor presence, routing, and other functionalities as discussed in moredetail above.

Home server(s) 614 may be assigned to client devices 601-603 as primaryand/or backup clusters. Presence server(s) 616 may store routing rulesfor users and provide updated replicas to their assigned home serversaccording to various approaches described herein. A primary cluster mayhave one or more backup clusters. Moreover, primary and backup clustersmay have reversed roles for each other.

Client devices 601-603 and the servers of the system may communicatethrough SIP in routing requests through one or more backup clusters.Data associated with the system configuration (e.g. user names, phonenumbers, call policies, configuration, records, etc.) and other networkrelated operations may be stored in one or more data stores such as datastores 626, which may be directly accessed by the servers and/or clientsof the system or managed through a database server 624. UCN 610 providesthe backbone of the UC system and may employ a number of protocols suchas SIP, RTP, and the like. Client devices (e.g. 601-603) provideplatforms for UCN user end points. Users may access the communicationsystem using a client device or one or more client applications runningon a client device.

UCN 610 provides communication between the nodes described herein. Byway of example, and not limitation, UCN 610 may include wired media suchas a wired network or direct-wired connection, and wireless media suchas acoustic, RF, infrared and other wireless media.

Many other configurations of computing devices, applications, datasources, data distribution systems may be employed to implementresilient routing. Furthermore, the networked environments discussed inFIG. 6 are for illustration purposes only. Embodiments are not limitedto the example applications, modules, or processes.

FIG. 7 and the associated discussion are intended to provide a brief,general description of a suitable computing environment in whichembodiments may be implemented. With reference to FIG. 7, a blockdiagram of an example computing operating environment for an applicationaccording to embodiments is illustrated, such as computing device 700.In a basic configuration, computing device 700 may be a server managinga communication application or service such as a registrar server (orhome server) and include at least one processing unit 702 and systemmemory 704. Computing device 700 may also include a plurality ofprocessing units that cooperate in executing programs. Depending on theexact configuration and type of computing device, the system memory 704may be volatile (such as RAM), non-volatile (such as ROM, flash memory,etc.) or some combination of the two. System memory 704 typicallyincludes an operating system 705 suitable for controlling the operationof the platform, such as the WINDOWS ® operating systems from MICROSOFTCORPORATION of Redmond, Washington. The system memory 704 may alsoinclude one or more software applications such as program modules 706,communication application 722, and replication module 724.

Communication application 722 may be any application that facilitatescommunication between client applications that connect to computingdevice 700 and servers relevant to an enhanced communication system suchas other home servers, mediation servers, and presence servers.Replication module 724 may maintain a replica of routing rules for usersassigned to computing device 700 and update the replica throughsynchronization with an assigned presence server as described above.Replication module 724 and communication application 722 may be separateapplications or integral modules of a hosted service that providesenhanced communication services to client applications/devices. Thisbasic configuration is illustrated in FIG. 7 by those components withindashed line 708.

Computing device 700 may have additional features or functionality. Forexample, the computing device 700 may also include additional datastorage devices (removable and/or non-removable) such as, for example,magnetic disks, optical disks, or tape. Such additional storage isillustrated in FIG. 7 by removable storage 709 and non-removable storage710. Computer readable storage media may include volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information, such as computer readableinstructions, data structures, program modules, or other data. Systemmemory 704, removable storage 709 and non-removable storage 710 are allexamples of computer readable storage media. Computer readable storagemedia includes, but is not limited to, RAM, ROM, EEPROM, flash memory orother memory technology, CD-ROM, digital versatile disks (DVD) or otheroptical storage, magnetic tape, magnetic disk storage or other magneticstorage devices, or any other medium which can be used to store thedesired information and which can be accessed by computing device 700.Any such computer readable storage media may be part of computing device700. Computing device 700 may also have input device(s) 712 such askeyboard, mouse, pen, voice input device, touch input device, andcomparable input devices. Output device(s) 714 such as a display,speakers, printer, and other types of output devices may also beincluded. These devices are well known in the art and need not bediscussed at length here.

Computing device 700 may also contain communication connections 716 thatallow the device to communicate with other devices 718, such as over awired or wireless network in a distributed computing environment, asatellite link, a cellular link, a short range network, and comparablemechanisms. Other devices 718 may include computer device(s) thatexecute communication applications, presence servers, and comparabledevices. Communication connection(s) 716 is one example of communicationmedia. Communication media can include therein computer readableinstructions, data structures, program modules, or other data. By way ofexample, and not limitation, communication media includes wired mediasuch as a wired network or direct-wired connection, and wireless mediasuch as acoustic, RF, infrared and other wireless media.

Example embodiments also include methods. These methods can beimplemented in any number of ways, including the structures described inthis document. One such way is by machine operations, of devices of thetype described in this document.

Another optional way is for one or more of the individual operations ofthe methods to be performed in conjunction with one or more humanoperators performing some. These human operators need not be collocatedwith each other, but each can be only with a machine that performs aportion of the program.

FIG. 8 illustrates a logic flow diagram for process 800 of updating anddisseminating user routing rules in primary/backup cluster architectureaccording to embodiments. Process 800 may be implemented as part of anenhanced communication system on a home server.

Process 800 begins with operation 810, where upon detecting a login of auser, the assigned registrar sends a notification message to itsassigned presence server. The notification message may include a versionof the replica routing rules at the registrar. At operation 820, theregistrar may receive a list of batches with their versions from thepresence server after the presence server computes the list of batchesfor the user. At operation 830, the registrar may determine batches tobe requested from the presence server based on comparing the versionsreturned by the presence server to the versions known to the registrar.

Subsequently, the registrar may request the batches with differentversions individually from the presence server by submitting batchidentifiers and versions at operation 840. At following operation 850,updates to the requested batches may be received from the presenceserver and the batches updated at the registrar along with theirversions at operation 860. Once all batches are updated, the registrarmay update its replica version reflecting the latest synchronizationwith its assigned presence server at operation 870.

The operations included in process 800 are for illustration purposes.Continuous replication for SIP based communication systems according toembodiments may be implemented by similar processes with fewer oradditional steps, as well as in different order of operations using theprinciples described herein.

The above specification, examples and data provide a completedescription of the manufacture and use of the composition of theembodiments. Although the subject matter has been described in languagespecific to structural features and/or methodological acts, it is to beunderstood that the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims and embodiments.

What is claimed is:
 1. A method executed on a computing device forproviding continuous replication of routing rules, the methodcomprising: detecting an agreement between a processor of a presenceserver and a processor of a registrar server on a common protocoldesigned to minimize data transfer; upon detecting a user log-in at theprocessor of the registrar server, providing the processor of thepresence server with a version of a current routing rules replica storedat data storage of the registrar server; receiving a list of routingrules and current versions of the routing rules from the processor ofthe presence server, wherein the list of routing rules and currentversions of the routing rules are comprised of batches; determiningout-of-date routing rules at the processor of the registrar server;requesting updates for the out-of date routing rules from the processorof the presence server; wherein the request includes a registrar clusteridentification, a batch identifier, and a batch version, each batchversion including a major version and a minor version; employing amajor/minor versioning scheme to compute batch deltas in order toprovide update information, wherein: in response to determination that amajor version for a batch matches a major version of a batch receivedfrom a processor of the registrar server, modified resources aredetermined in each batch based on a comparison of minor versions ofreceived and stored batches at a processor of the presence server tocompute the batch deltas; and in response to determination that themajor version for a batch does not match the major version of a batchreceived from the processor of the registrar server, a list of usersassociated with the batch is obtained, and information is sent back foreach user in the list that is assigned to the processor of the registrarserver; receiving the update information associated with the out-of-daterouting rules at the processor of the registrar server; and updating therouting rules stored at the processor of the registrar server andversions of the updated routing rules.
 2. The method of claim 1, furthercomprising: updating the version of the replica of routing rules storedat the registrar upon completion of the update of routing rules.
 3. Themethod of claim 1, further comprising: upon receiving a routing rulechange from the logged in user, routing the change as a request to theprocessor of the presence server; and receiving updated routing rulefrom the processor of the presence server for storing at the processorof the registrar.
 4. The method of claim 3, wherein the user is enabledto change the routing rule if the processor of the presence server isavailable, wherein calls directed at the user are processed according torouting rules currently stored at the processor of the registrar serverif the processor of the presence server is unavailable.
 5. The method ofclaim 1, wherein the registrar is one of: a home server for the user anda backup server assigned to the home server for the user.
 6. The methodof claim 1, wherein the routing rules are stored as part of a routingpayload, the routing payload comprising at least one from a set of: therouting rules, a privacy relationship setting, and a hierarchicalrelationship setting.
 7. The method of claim 1, further comprising:periodically querying the processor of the presence server for changesto the routing payload associated with users assigned to the registrar.8. The method of claim 1, further comprising: employing versionedbatches to exchange update information about out-of-date routing rules.9. The method of claim 1, wherein the registrar server and the presenceserver are part of clusters.
 10. The method of claim 1, wherein theprocessor of the registrar server and the processor of the presenceserver exchange messages via Session Initiation Protocol (SIP).
 11. Acomputing device for providing continuous replication of routing rules,the computing device comprising: a processing unit; a memory; and theprocessing unit coupled to the memory, the processing unit executing acommunication application, wherein the communication application isconfigured to: detect an agreement between a presence server and aregistrar server on a common protocol designed to minimize datatransfer; upon detecting a user log-in, notify the presence server witha version of a current routing rules replica stored at the registrarserver using the protocol to reduce the data transfer between thepresence server after an initial notification; determine out-of-daterouting rules based on a comparison of versions of a list of routingrules received from a presence cluster assigned to a registrar cluster,wherein the versions of the list of routing rules comprise versionedbatches that are compared to exchange update information about theout-of-date routing rules; request updates for the out-of date routingrules from the presence cluster, wherein the request includes aregistrar cluster identification, a batch identifier, and a batchversion, each batch version including a major version and a minorversion; employ a major/minor versioning scheme at the presence clusterto compute batch deltas, wherein: in response to determination that amajor version for a batch matches a major version of a batch receivedfrom a processor of the registrar server, modified resources aredetermined in each batch based on a comparison of minor versions ofreceived and stored batches at a processor of the presence server tocompute the batch deltas; and in response to determination that themajor version for a batch does not match the major version of a batchreceived from the processor of the registrar server, obtain a list ofusers associated with the batch, and send back the information for eachuser in the list that is assigned to the processor of the registrarserver; provide the batch deltas to the registrar cluster; update therouting rules stored at the registrar cluster and versions of theupdated routing rules based on the batch deltas received from thepresence cluster; and in response to the notification from the registrarcluster, send a current replica version and a current list of routingrules to the registrar cluster; determine update information for eachout-of-date routing rule based on the update requests from the registrarcluster; provide the update information to the registrar cluster; andupdate the current replica version.
 12. The computing device of claim11, wherein the communication application is further configured to:assign at least one backup cluster to the registrar cluster and assign abackup cluster to the presence cluster, wherein the registrarcluster/presence cluster combination assigned to a user and a backupconfiguration for the clusters is published globally within the systemsuch that the user is enabled to connect to the system through aregistrar cluster other than the assigned registrar cluster.
 13. Thecomputing device of claim 11, wherein the communication application isfurther configured to: provide the entire routing rules to the registrarcluster during an initial synchronization and provide updates to changedrule during subsequent synchronizations such that a state of thepresence cluster is maintained at the registrar cluster assigned to theuser.
 14. The computing device of claim 11, wherein the routing rulesinclude at least one from a set of: a time based rule, a relationshipbased rule, a caller based rule, and an end point selection rule forrouting calls associated with the user.
 15. The computing device ofclaim 11, wherein the registrar cluster is one of: a branch officecluster configured to exchange messages with the presence clusterthrough Hypertext Transfer Protocol (HTTP) and a data center clusterconfigured to exchange messages with the presence cluster via directcall.
 16. A computer-readable memory device with instructions storedthereon for providing continuous replication of routing rules, theinstructions comprising: detecting an agreement between processors of apresence cluster and processors a registrar cluster on a common protocoldesigned to minimize data transfer; periodically querying the processorsof the presence cluster for changes to a routing payload comprising atleast one from a set of: routing rules, a privacy relationship setting,and a hierarchical relationship setting associated with users assignedto the processors of the registrar cluster; upon detecting a user log-inat the registrar cluster, notifying the processors of the presencecluster with a version of a current routing rules replica stored at theprocessors of the registrar cluster; receiving a list of the routingrules and current versions of the routing rules from the processors ofthe presence cluster; determining out-of-date routing rules by comparingthe received versions to versions of the routing rules cached at theprocessors of the registrar cluster, wherein versions of the routingrules are comprised of versioned batches; requesting individual updatesfor the out-of date routing rules from the processors of the presencecluster, wherein the request includes a registrar clusteridentification, a batch identifier, and a batch version, each batchversion including a major version and a minor version; employing amajor/minor versioning scheme at the processors of the presence clusterto compute batch deltas, wherein: in response to determination that amajor version for a batch matches a major version of a batch receivedfrom a processor of the registrar cluster, modified resources aredetermined in each batch based on a comparison of minor versions ofreceived and stored batches at a processor of the presence cluster tocompute the batch deltas; and in response to determination that themajor version for a batch does not match the major version of a batchreceived from the processor of the cluster, obtain a list of usersassociated with the batch, and send back information for each user inthe list that is assigned to the processor of the registrar cluster;receiving update information associated with the out-of-date routingrules at the processors of the registrar cluster from the batch deltasprovided by the processors of the presence cluster; updating the routingrules and versions of the routing rules cached at the processors of theregistrar cluster; and updating the version of the current routing rulesreplica at the processors of the registrar cluster.
 17. Thecomputer-readable memory device of claim 16, wherein the instructionsfurther comprise: if the registrar cluster becomes unavailable, enablinguser access through another registrar cluster and implement the routingrules stored at the presence cluster by providing the routing payload toprocessors of the other registrar cluster.
 18. The computer-readablememory device of claim 16, wherein the instructions further comprise:enforcing the routing rules even if the user if logged out and theprocessors of the presence cluster is unavailable.
 19. Thecomputer-readable memory device of claim 16, wherein the routing rulesare implemented for multi-modal calls associated with the usercomprising at least one from a set of: an audio communication, a videocommunication, an email exchange, a text message exchange, a datasharing session, a whiteboard sharing session, and an applicationsharing session.